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The Applicant's Appeal brief is re-submitted in response to the Office's 
Notification under 37 CFR 41.37 

(1) Real Party in Interest: The application is assigned to Discovery Machines, 
Inc., the real party in interest. 

(2) Related appeals and interferences: None. 

(3) Status of Claims: All of the claims are appealed. Claims 1-20 are pending 
and rejected. Claims 1, 11 and 16 are objected to, more specifically: 
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c) 
d) 
e) 
f) 



a) 
b) 



Claims 1-10 are rejected on 35 USC 101. 

Claims 1, 11 and 16 are objected to on an informality of unspecified 
legal basis. 

Claims 1 and 10 are rejected on 35 USC 102. 
Claims 2-6 and 11-18 are rejected on 35 USC 103(a). 
Claims 7 and 8 are rejected on 35 USC 103(a). 
Claims 9 and 19-20 are rejected on 35 USC 103(a). 



(4) Status of Amendments: Amendments were proposed after Final Rejection 
and all were disallowed by the Advisory Action mailed April 1, 2005. A copy of 
the proposed amendments is attached hereto in which: 



(5) Summary of the Claimed Subject Matter: 

The invention relates to both software and computer systems (with hardware 
claim integers) that enable a user to utilize a plurality of knowledge acquisition 
approaches to find a solution to a task. 



As recited in claim 1 (and with reference to the specification and drawing 
reference numbers recited in the specification), software recorded on a 
computer-readable medium (400 and Figure 4 generally; see also page 4 first 
paragraph) enables a user to utilize a plurality of knowledge acquisition 
approaches. The "plurality" referred to in the claims comprises TMK and SBF. 
The description deals with how the TMK and SBF approaches are integrated at 
for example pages 9 and 10, and with specific reference to the fourth paragraph of 
page 8 (beginning with the words "Referring now to Fig.4...") . As recited in claim 



• Claims 1,2,11 and 16 were sought to be amended 

• Claim 3 was deleted 



Claim 1 
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l, the software enables a user to find a solution to a task using a task-method- 
knowledge (TMK) approach and a structure-behavior-function approach (SBF), 
as follows. 

A task is acquired by receiving information specifying at least one input 
parameter 414, one output parameter 414, and an initial approach (i.e. 
determination) 416. The invention then recites analyzing the provided 
information using the task-method-knowledge approach 418 and the structure- 
behavior-function approach 432 based on the specified initial approach 416. 

Claim 1 then recites processing the task 420-430 using the determined 
approach to achieve a solution (420-30 for TMK, or 434 - 436 for SBF), the 
processing utilizing the input parameter 414. The recited processing further 
comprises using a structure-behavior-function behavior and encoding the 
behavior using a task-method-knowledge hierarchy which is collected from the 
user 444. The claimed processing further comprises using a task-method- 
knowledge hierarchy and encoding the input parameter and the output 
parameter using a structure-behavior-function model which is collected from the 
user as explained on page 10, paragraph 1 (In step 448...). 

Claim 11 

A computer-readable medium for storing a computer executable software 
program (400 and Figure 4 generally; see also page 4 first paragraph) determines 
a solution to a task using a plurality of knowledge acquisition approaches. The 
"plurality" referred to in the claims comprises TMK and SBF. The description 
deals with how the TMK and SBF approaches are integrated at for example pages 
9 and 10, and with specific reference to the fourth paragraph of page 8 (beginning 
with the words "Referring now to Fig. 4..."). 

The recited software program includes instructions for defining the task as 
an input parameter collected from a user 414, encoding using a first structure- 
behavior-function model 448. The software defines the solution as an output 
parameter collected from the user 414, 448, encoded using a second structure- 
behavior-function model 448. 
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Claim 11 then recites selecting a knowledge acquisition approach from a 
group consisting of a task-method-knowledge approach or a structure-behavior- 
function approach 416 and then processing the task using the selected approach 
418-458 (see also pages 9 and 10). 

The invention recited in claim 11 then recites determining whether the task 
includes at least one portion to be processed using the non-selected approach 452, 
456, and finally the determining of the solution of the task using a structure- 
behavior-function behavior and encoding the behavior using task-method- 
knowledge hierarchy which is collected from the user 444. 

Claim 16 

Claim 16 recites a computer system for providing a solution to a task. The 
system is illustrated by way of example in Figure 1 and discussed on page 3. The 
system has a processor 102 and a memory 104 accessible to the processor and 
software, a portion of which is stored in the memory. 

The software includes instructions for accepting at least a first parameter 
414, encoded as a first structure-behavior-function model 448, to define the task. 
The software accepts at least a second parameter 414, encoded as a second 
structure-behavior-function model 448, to define the solution. The claimed 
software accepts an initial approach for processing the task 416. It then 
determines whether to use a task-method-knowledge approach 418 or a 
structure-behavior-function approach 432 for processing the task or the 
determination based on the specified initial approach 416. The software 
processes the task using the determined approach based on the first parameter 
(418-430 for TMK and 432-446 for SBF). 

The processing of the task further comprises using a structure-behavior- 
function behavior and encoding the behavior using a task-method-knowledge 
hierarchy which is collected from a user 444, and finally determining 458 
whether the solution is found based on the second parameter. 



4 



(6) Grounds of Rejection to be Reviewed on Appeal: 

a) If the Examiner was wrong to fail to enter the amendments after 
Final Rejection. 

b) If claims 1-10 lack statutory subject matter under 35 USC 101. 

c) If claims 1, 11 and 16 are defective for failure to spell out acronyms. 

d) If Goel et al anticipates either of claims 1 or 10 under 35 USC 102(b). 

e) If the examiner was wrong to reject claims 2-6 and 11-18 under 35 
USC 103(a) on the basis of Goel et al in view of Scott. 

f) If the examiner was wrong to reject claim 4 under 35 USC 103(a) on 
the basis of Goel et al in view of Scott. 

g) If the examiner was wrong to reject claims 7 and 8 under 35 USC 
103(a) on the basis of Goel et al in view of Scott and Goward. 

h) If the examiner was wrong to reject claims 9 and 19-20 under 35 
USC 103(a) on the basis of Goel and Nasr. 

(7) Argument: 

The arguments below are made with respect to like numbered sub-headings a) - g) 
in the above section (6). 

a. The Claims Submitted After Final Rejection Should Have Been 
Entered 

The examiner's final rejection was mailed Oct., 22 2004. A second 
amended claim set and arguments were filed with extension fees on 21 March, 
2205. These amendments were not entered because the examiner contended that 
the amended claims raised new issues and/or would require a new search. 

In essence, the amendments merely clarified promoted subject matter 
from dependent claims into the independent claims. Subject matter from claim 4 
was promoted to claim 1. The notions introduced into claim 1 were squarely 
before the examiner at all times and could only be considered new to the 
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prosecution if one were to accept that the examiner had failed to previously 
consider all of the dependent claims and the specification. 

b. Claims 1-10 are Statutory Subject Matter 

The objections based on section 101 are understood to have been raised for 
the first time on final rejection, giving the applicant no opportunity to respond. 
Software is widely regarded as patentable. The applicant is willing to make the 
requested changes and has done so in its rejected submissions after final 
rejection. The rejected amendments after final rejection are now attached 
reflecting these changes. It is requested that the claims re-enter prosecution for 
the purpose, if nothing else, of effecting the changes sought by the examiner. 

As a matter of interpretation, the term "software 11 is commonly understood, 
if only for the sake of this argument, to comprise either inchoate instructions, 
which is never the case in reality, or more commonly, those same instructions 
reduced to a machine readable form (which is always the case in reality). As the 
one definition borders on the absurd and the other is squarely within the bounds 
of 35 USC 101, it is submitted that the rules for resolving ambiguity demand that 
the sensible interpretation be applied and that the absurd one be disregarded. 

Thus, using the most common interpretation of "software" even those 
claims rejected before final rejection are considered statutory under section 101 
and the claim amendments made after final rejection recite the tangible medium 
and are clearly within the bounds of section 101. 

c. Claims l, 11 and 16 are not Defective for Failure to Spell out 
Acronyms 

The claims would be defective only if their meaning were ambiguous or 
lacking in clarity. Neither proposition is specifically named by the examiner as 
being at issue. Again, it is unfair these issues raised for the first time at final 
rejection. 
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The examiner must know exactly what the terms mean as would a person 
of ordinary skill in this art at the time the invention was made. 

The examiner has failed to cite any portion or the USC or CFR in support 
of his demand. How is the applicant to gauge the basis of the objection? In any 
event, the changes were offered and rejected after final. Conforming amendments 
are offered now. 

d. Goel does not Anticipate any Claim, Particularly Claim 1 or 10 

According to the Manual of Patent Examining Procedure, Section 2131, "a 
claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference". 
This section of the MPEP contains abundant case law citations to support the 
same proposition. In this instance, it is a fact that Goel fails to disclose 
knowledge acquisition methods as found in each claim under appeal. 

The crux of this appeal can be found in the examiner f s reliance on the 
factually incorrect statement that: "Goel et al. discloses a process for enabling a 
user to utilize a plurality of knowledge acquisition approaches to find a solution 
to a task." 

Goel et al. ("Goer 1 ) does not disclose a knowledge acquisition approach. 
He discloses a knowledge processing approach. The difference between the two 
is that an acquisition approach is a method that requests and acquires or obtains 
knowledge from a user during processing. Goel et al.'s method is to encode, in 
advance, all knowledge before processing. During processing, Goel et al. use a 
computer interface to "visually illustrate the system's reasoning" (abstract lines 
6-7, and Figure 2.). 

The claimed invention requests knowledge from a user, a deficiency in 
Goel acknowledged by the examiner in his response (paragraph 7 paragraph 3). 
The examiner states, "Goel ... [uses a] process comprising acquiring a task by 
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receiving information specifying at least one input parameter, one output 
parameter and an initial approach, analyzing the provided information to 
determine whether to process the task using the TMK approach or the SBF 
approach to achieve a solution." This is incorrect. Rather, Goel uses a fixed 
method of problem solution, comprising the four tasks Problem Elaboration, 
Case Retrieval, Design Adaptation, and Case Storage, and sub-tasks related to 
these four tasks (page 2 paragraph 4, figure 1, page 6 paragraph 4 last sentence). 

The claimed invention receives from a user an initial approach, and then 
determines to use TMK or SBF after analysis. 

The examiner states that Goel, "... [determines] whether to process the 
task using the TMK approach or the SBF approach based on the specified initial 
approach". This is incorrect. Rather, Goel et al. "... use TMK models for 
describing reasoning about a design problem" (page 2 line 2, Figure 2), and "[use] 
device models described in the SBF language for adapting a past design and for 
evaluating a candidate design", and "all modification methods make use of SBF 
device models" (page 3 last paragraph). Goel et al. states, "TMK [is used] for 
describing reasoning about a design problem" (page 2 paragraph 1), and "uses the 
TMK model of Kritik3's reasoning to graphically illustrate and explain how the 
system generates new designs." 

The invention of claim 1 and its dependencies, "[processes] the task using 
the determined approach to achieve a solution" and does not use a fixed four-task 
approach. In fact, the claimed invention accepts as user input, both TMK and 
SBF, providing a flow during acquisition between acquiring process knowledge, 
then device knowledge, then process knowledge, etc. 

The examiner does not address "the processing further comprising using 
an SBF behavior and encoding the behavior using a TMK hierarchy which is 
collected from the user". Again, Goel teaches using TMK only as a means for 
"describing reasoning about a design problem". Encoding the behavior of an SBF 
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model as a TMK hierarchy is new and non-obvious inventive aspect of the 
disclosed invention. 

e. Claims 2-6 and 11-18 are Allowable under 35 USC 103 

Claim 2-6 and 11-18 are rejected in paragraph 7 of the October 22, 2004 
Supplemental Office Action. The Examiner's reasoning with regard to the 35 USC 
103 rejections is deeply flawed. The deficiencies of Goel are discussed above. 
Further, the analysis of the Scott reference ("Scott") reveals a lack of 
understanding of both Scott and the claimed invention. Lastly, the manner of the 
combination made by the Examiner, of Goel and Scott is not within the bounds of 
what the law will allow. 

The examiner correctly acknowledges that Goel "[fails] to clearly disclose 
defining the method if the method does not exist." The examiner also states that 
Goel teaches, "selecting by method if the method does exist." This is factually 
incorrect. Rather, Goel et al. teach a system for processing a fixed encoded 
knowledge base. Goel then "visually illustrates the system's reasoning". There is 
no interaction with the user, neither "selecting by user input the method" nor 
"acquiring a user-defined method". 

The 35 USC 103 rejections stem from a fundamental failure to consider the 
limitations in claim 2 and to consider the content of Scott. The examiner states 
"Scott further discloses defining the method if the method does not exist 
(abstract lines 6-11)." The referenced lines of said Abstract state, "The knowledge 
system provides automatic programming for solving problems within a particular 
domain, rejects problems that cannot be solved using the available capabilities of 
the target computer, and explains why a program cannot be generated to solve a 
given problem." Elements 84, 85, and 86 of Figure 3 of Scott explain what is 
meant by the quoted abstract reference, stating, "Apply rules to generate a 
diagnosis of rejection of the problem", "Trace application of rules or otherwise 
generate an explanation of reasons for the diagnosis", and "Output diagnosis that 
problem cannot be solved and explanation why", respectively. That is, Scott 
teaches collecting a problem description from a user (element 81, figure 3), 
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testing for a solution (element 83), and outputting an explanation why there is 
not solution if no solution exists (element 86). The next step after element 86 is 
"Stop". Thus, the user is left to enter another definition of the problem at 
element 81, possibly using the explanation of element 86 to alter the original 
definition. Essentially, Scott teaches, "The system cannot solve the problem you 
entered, enter a different problem". By contrast, the present invention acquires a 
user-defined method if no method is found "operable to provide at least a portion 
of the solution" (claim 2). That is, in lay terms, "the system is missing a part that 
would forward solution of your problem, so keeping the same problem 
description , please provide the missing portion of the solution ." Such difference 
in approach is not taught nor even suggested by Scott. 

Furthermore, Scott does not teach nor imply the limitations from claim 2 
relating to a method step of "selecting by user input the method if the method 
exists." Rather, Scott teaches to: "generate an explanation of why the design is 
appropriate" (element 88, figure 3). That is, the system of Scott selects a method 
if the method exists and provides an explanation of why it was selected. If no 
method exists, Scott teaches providing an explanation of why it does not exist. 
There is no teaching of user input directing selection of a method leading to a 
solution to the input problem. The only user input of Scott is the definition of the 
problem and nothing regarding the selection of a solution. 

Scott, therefore, does not teach "acquiring a user-defined method if the 
method does not exist" nor "selecting by user input the method if the method 
exists. Similarly for claim 4, "acquiring a user-defined model if the model does 
not exist", Scott teaches acquiring from a user a problem definition. If the Scott's 
system cannot solve the defined problem, an explanation of why not is given the 
user. The user is not able to input any portion of the solution, only problem 
definitions. 

Scott, therefore, does not teach "acquiring a user-defined model if the 
model does not exist". Scott does not teach nor imply "encoding the behavior into 
the model using the TMK approach if the behavior does not exist." Again, in 
Scott's system, the only input the user provides is a problem definition. If no 
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solution to that problem exists, the user can enter another problem, and not any 
part of the solution, as is taught by the present invention. 

Claims 2-6 and 11-18 stand rejected under 35 USC 103. The Applicant 
contends that the examiner has not met his burden on the issue of obviousness 
and that neither the facts nor the law supports the examiners conclusions. The 
law is clear and well established in this area and the examiner's conclusions 
cannot be sustained. 

Patent examiners carry the responsibility of making sure that the standard of 
patentability enunciated by the Supreme Court and by the Congress is applied in 
each and every case. The United States Supreme Court, in Graham v. John Deere, 
383 U.S. 1, 148 USPQ 459 (1966), stated: 

Under § 103, the scope and content of the prior art are to be determined; 
differences between the prior art and the claims at issue are to be 
ascertained; and the level of ordinary skill in the pertinent art resolved. 
As is evident from the MPEP, USPTO policy is to follow Graham v. John Deere Co. 
in the consideration and determination of obviousness under 35 U.S.C. 103. The 
factual inquires enunciated therein require, without exception: 

(A) Determining the scope and contents of the prior art; 

(B) Ascertaining the differences between the prior art and the claims in 
issue; and 

(C) Resolving the level of ordinary skill in the pertinent art. 

Accordingly, examiners should apply the test for patentability under 35 U.S.C. 
103 set forth in Graham. Further, in applying Graham: 

• The claimed invention must be considered as a whole. Here 
important tracts of every claim, particularly in relation to knowledge 
acquisition (claim 1 and etc.), acquiring user defined method (claim 2 and 
etc.) encoding behavior into the model using TMK (claim 4 and etc.) have 
been overlooked by the examiner. 
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• The references must be considered as a whole and must suggest the 
desirability and thus the obviousness of making the combination. The 
Examiner has shown no motive, teaching or suggestion stemming from the 
art for the combinations he suggests. 

• The references must be viewed without the benefit of impermissible 
hindsight vision afforded by the claimed invention. There being no motive, 
teaching or suggestion from the art, the combinations made by the 
examiner, must be considered hindsight reconstruction based on the 
benefits conferred to the examiner by the Applicant's disclosure. 

Hodosh v. Block Drug Co., Inc., 786 F.2d 1136, 1143 n.5, 229 USPQ 182, 187 n.5 
(Fed. Cir. 1986). 

Considering the Examiner's 103 rejections as a whole, it would appear that the 
examiner has made significant errors in the application of the Graham tests. 
He has failed to consider the limitations in the claims as explained above and 
below. When limitations are ignored and references misinterpreted he cannot be 
said to taking into account the content of the prior art. In the combinations of 
Goel and Scott he has failed to ascertain the differences between the art and the 
claims. In addition, no determination, evidence or even naked assertion is made 
about the level of ordinary skill in the art at the time the invention was made. 

f. Claim 4 is Allowable under 35 USC 103 

With specific reference to claim 4, important limitations in Claim 4 are 
completely ignored by Goel and Scott and are thus missing from these references. 
Scott does not teach the explicit limitation of claim 4, "encoding the behavior into 
the model using the TMK approach if the behavior does not exist." In Scott, the 
user provides a problem definition, the system of Scott analyses the problem and 
provides an explanation of why the problem cannot be solved if no solution exists. 
The user then can provide another problem description, possibly using the 
explanation to alter the definition. That is, it's the user that determines what 
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alteration to make. In the system of the present invention, the invention 
determines that a portion of the solution is missing, and asks the user to provide 
that portion in the form of a model (claim 2) or a behavior (claim 4). That is, it's 
the system of the present invention that not only determines that no solution is 
possible (which Scott teaches), but also what is missing and allows the user to 
provide what is missing. It is true that Scott explains why no solution is possible 
and allows the user to provide a different problem definition. This is not the 
same as allowing the user to provide that portion of the solution that is missing. 
If the user wants a solution to problem A, Scott's system can say why it cannot 
solve A, but there is nothing the user can do to have Scott's system solve A. The 
user may alter the problem definition to a new problem B that Scott's system can 
solve, but there is nothing the user can do to allow Scott's system to solve 
problem A. 

In contrast, the system of the claimed invention allows the user to provide, 
as methods or behaviors, missing parts of the solution. So if the user wants a 
solution to A, and no solution exists, the system of the claimed invention acquires 
from the user models or behaviors that provide a missing part of the solution. 
The result is a solution to the desired problem A, not the solution to another 
problem B, altered so the fixed system (of Scott) can solve it. Said another way, 
there are problems that Scott's system can solve, and others that it cannot solve. 
There is nothing the user can do to have Scott's system solve a problem that it 
can't solve. The set of solvable problems is fixed. The system of the present 
invention also has some problems that it can solve and some that it can't solve. 
But given a problem that it can't solve, it interacts with the user to provide what is 
missing so a solution is found. The set of solvable problems is not fixed. 

Thus, Scott neither teaches nor suggests any method for expanding the set 
of problems solvable by a system. Even the combination of Scott and Goel, does 
not teach acquiring from a user a portion of a solution if a system determines that 
that portion does not exist. Scott teaches altering the definition of the problem 
until the definition can be solved by the fixed system. Goel does not teach 
acquiring models or behaviors from a user under any circumstance. 
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Therefore, at a factual level, no rational combination of Goel and Scott teaches 
the subject matter of the claims rejected by the Examiner's paragraph 7. 
Therefore, and if for no other reason, the section 103 rejections must fall. 

The examiner has also failed to consider the scope of the claims by totally 
overlooking limitations in claim 4 and misinterpreting claim 4. The examiner 
states, "Regarding claim 4, ... Goel et al. further discloses a process including 
defining an event, the event operable to identify when to use the method." In 
contrast claim 4 states "searching a plurality of behaviors for behavior applicable 
to the model; selecting the behavior if the behavior exists, the selection 
associating the behavior with the model." Goel does not teach examining 
behaviors within SBF models. Rather, Goel teaches "design adaptation", "model 
revision" and "model verification". In each teaching, what is examined, adapted, 
revised and verified is the function of the device / model, and not the behavior . 
Since a model comprises Structure, Behavior, and Function, Goel et al. teach only 
examination of model Function. Even extending Goel et al. technique to 
Structure and Behavior, Goel et al. do not teach "acquiring a user-defined model". 
Said another way, Goel teaches modifying existing models, selecting models for a 
storage of existing models, and visually illustrating reasoning about processing 
the models. Goel does not teach, suggest, or imply a means for collecting from 
the user a new model if a suitable model does not exist. 

Claim 4 further states, "encoding the behavior into the model using the 
TMK approach if the behavior does not exist." Goel et al. do not teach nor 
suggest this use of TMK. Rather Goel et al. teach using TMK "for describing 
reasoning about a design problem." 

g. Claims 7 and 8 are Allowable under 35 USC 103 

The deficiencies in the rejection of claims 1, 2 and 4 (from which claims 7 
and 8 depend), as argued above, are relied upon to sustain the proposition that 
the rejection of claims 7 and 8 was improper. 
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h. Claims 9 and 19-20 are Allowable under 35 USC 103 

The deficiencies in the rejection of claim 16, argued above, are relied upon 
to sustain the proposition that the rejection of claims 9 and 19-20 was improper. 
It appears that there was a clerical error in claim 9 and that the dependency 
should have made reference to claim 4. The applicant is willing to correct this 
clerical error if given the opportunity. 



VI. Summary 

The examiner has not met his burden with respect to any of the prior art 
objections. The claims and the specification are considered allowable and to the 
extent that there are matters requiring further attention or that can be remedied 
by amendment, the case should be returned for examination so that suitable 
amendments can be made. 

Respectfully, 




Michael Molins BES JD 



Patent Attorney for the Applicant 
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Appendix I - Second Amended Claim Set filed after Final Rejection 

1. (currently amended) Software, recorded on a computer-readable medium , 
for enabling a user to utilize a plurality of knowledge acquisition approaches to 
find a solution to a task using a task-method-knowledge approach and a 
structure-behavior-function approach, the software performing the steps of: 

acquiring a task by receiving information specifying at least one input 
parameter, one output parameter, and an initial approach; 

analyzing the provided information using the task-method-knowledge 
approach and er the structure-behavior-function approach based on the specified 
initial approach; 

processing the task using the determined approach to achieve a solution, 
the processing utilizing the input parameter; 

the processing further comprising using an SBF a structure-behavior-function 
behavior and encoding the behavior using a TMK task-method-knowledge 
hierarchy which is collected from the user; 

the processing further comprising using a task-method-knowledge 
hierarchy and encoding the input parameter and the output parameter using a 
structure-behavior-function model which is collected from the user . 

2. (currently amended) The software of claim l further including, if the 
determined approach is the task-method-knowledge approach: 

searching a plurality of existing methods for a method operable to provide 
at least a portion of the solution; 

selection, by user input, the method if the method exists; and acquiring a 
user-defined method, encoded using a task-method-knowledge hierarchy, if the 
method does not exist. 

3. (deleted) The software of claim 2 further including: 

searching a plurality of existing procedures for a procedure rather than 
searching for a method, the procedure operable to provide at least a portion of 
the solution; 
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selecting the procedure if the procedure exists; and acquiring a user- 
defined procedure if the procedure does not exist. 

4. (previously amended) The software of claim 2 further including, if the 
determined approach is the structure-behavior-function approach: 

searching a plurality of existing models for a model operable to provide at 
least a portion of the solution; 

selection the model if the model exists; 

acquiring a user-defined model if the model does not exist; 

searching a plurality of existing behaviors for a behavior applicable to the 

model; 

selecting the behavior if the behavior exists, the selection associating the 
behavior with the model; and 

encoding the behavior into the model using the task-method-knowledge 
approach if the behavior does not exist. 

5. (previously amended) The software of claim 4 wherein acquiring a user- 
defined model further includes: 

searching a plurality of existing components and existing connections for a 
first component, a second component, and a connection between the first and 
second components operable to represent the model; and 

if at least one of the first component, the second component, or the 
connection does not exist, defining the first component, the second component, 
or the connection which does not exist. 

6. (previously amended) The software of claim 4 further including mapping 
either the input parameter of or the output parameter to at least a portion of the 
first model, the mapping operable to assign the mapped parameter to the portion. 

7. (previously amended) The software of claim 4 further including defining 
an event, the event operable to identify when to use the method. 
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8. (previously amended) The software of claim 4 further including 
determining the existence of at least one other method. 

9. (previously amended) The software of claim 9 further including providing 
a processing order, the processing order operable to define the order in which the 
method will be processed relative to a plurality of other methods awaiting 
processing. 

10. (previously amended) The software of claim 1 further including: 
determining whether the user desired to modify at least one of the input or 

output parameters; and modifying at least one of the input or output parameters 
if the user so desires. 

11. (currently amended) A computer-readable medium for storing a 
computer executable software program for determining a solution to a task using 
a plurality of knowledge acquisition approaches, the program including 
instructions for: 

defining the task as an input parameter, collected from a user, encoded 
using a first structure-behavior-function model : 

defining the solution as an output parameter, collected from the user, 
encoded using a second structure-behavior-function model : 

selecting a knowledge acquisition approach from a group consisting of a 
task-method-knowledge approach or a structure-behavior-function approach 
processing the task using the selected approach; 

determining whether the task includes at least one portion to be processed 
using the non-selected approach; 

the determining of the solution of the task further comprising using an 
SBF a structure-behavior-function behavior and encoding the behavior using 
TMK task-method-knowledge hierarchy which is collected from a the user. 
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12. (currently amended) The medium of claim 11 wherein the program further 
includes instructions for storing an the output parameter generated by processing 
the portion; and using the output parameter as an input to the task. 

13. (original) The medium of claim 11 wherein the program further includes 
instructions for redefining the task if the solution is not found. 

14. (original) The medium of claim 11 wherein the program further includes 
instructions to provide at least one interface enabling interaction with the 
program. 

15. (original) The medium of claim 11 wherein the program further includes 
instructions for redefining the solution if the solution is not found. 

16. (currently amended) A computer system for providing a solution to a task 
through information processing, the system including: 

a processor; 

a memory accessible to the processor; and software, a portion of which is 
stored in the memory, the software including instructions for: 

accepting at least a first parameter , encoded as a first structure-behavior- 
function model, to define the task; 

accepting at least a second parameter , encoded as a second structure- 
behavior-function model, to define the solution; 

accepting an initial approach for processing the task; 

determining whether to use a task-method-knowledge approach or a 
structure-behavior-function approach for processing the task, the determination 
based on the specified initial approach; 

processing the task using the determined approach based on the first 
parameter 

the processing of the task further comprising using an SBF a structure- 
behavior-function behavior and encoding the behavior using a TMK task- 
method-knowledge hierarchy which is collected from a user, and 



19 



determining whether the solution is found based on the second parameter. 

17. (original) The system of claim 16 wherein the software further includes 
instructions for, if the determined approach is the task-method-knowledge 
approach: 

determining whether a first portion of the task should be processed 
independently; 

determining whether to use the task-method-knowledge approach or the 
structure-behavior-function approach for processing the first portion if the first 
portion of the task should be processed independently; and 

processing the first portion using the determined approach. 

18. (original) The system of claim 17 wherein the software further includes 
instructions for, if the determined approach is the structure-behavior-function 
approach: 

determining whether a second portion of the task should be processed 
independently using the task-method-knowledge approach; and 

processing the second portion using the task-method-knowledge approach 
if the second portion should be processed independently. 

19. (original) The system of claim 16 wherein the software further includes 
instructions for modifying the first parameter if the solution is not found. 

20. (original) The system of claim 16 wherein the software further includes 
instructions for modifying the second parameter if the solution is not found. 
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Appendix II - Claim Set Rejected by Examiner's Final Rejection 
These claims appear on the following 7 pages, numbered 1-7. 
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;EP26 2005 J AMENDED CLAIMS 



1. 



Software A process for enabling a user to utilize a plurality of 



knowledge acquisition approaches to find a solution to a task using -r4be 
know le dg e acquis i tion approaches inc l uding a task-method-knowledge 
approach and a structure-behavior-function approach, the software proc e ss 
comprising performing the steps of : 

acguiring a defining tho task by providing recieving information specifying 
at least one input parameter, one output parameter, and an initial approach; 

analyzing the provided information to d e termi ne wh e th e r to proc e ss th e 
task using the task-method-knowledge approach or the structure-behavior- 
function approach based on the specified initial approach ; 

processing the task using the determined approach to achieve a solution, 
the processing utilizing the input parameter; 

the processing further comprising using an SBF behavior and encoding the 
behavior using a TMK hierarchy which is collected from the user. an4 
det e rmin i ng whothortho so l ution is correct by comparing th e solut i on w i th the 
output parameter. 

2. (amended) The software proc e ss of claim 1 further including, if the 
determined approach is the task-method-knowledge approach: 

searching a plurality of existing methods for a method operable to 
provide at least a portion of the solution; 

selecting , by user input the method if the method exists; and 
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acquiring a user defined defining the method if the method does not 

exist. 

3. (amended) The software proc e ss of claim 2 further including: 
searching a plurality of existing procedures for a procedure rather than 
searching for the method, the procedure operable to provide at least a portion 
of the solution; 

selecting the procedure if the procedure exists; and acquiring the 
procedure if the procedure does not exist. 

4. (amended) The software proc e ss of claim 2 further including, if the 
determined approach is the structure-behavior-function approach: 

searching a plurality of existing models for a model operable to provide 
at least a portion of the solution; 

selecting the model if the model exists; 

acquiring a user defined def i n i ng th e model if the model does not exist; 
searching a plurality of existing behaviors for a behavior applicable to the 
model; 

selecting the behavior if the behavior exists, the selection associating the 
behavior with the model; and 

encoding the behavior into the model using the task-method- 
knowledge approach if the behavior does not exist 
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5. (amended) The software proc e ss of claim 4 wherein acquiring a user 
defined defining tho model further includes: 

searching a plurality of existing components and existing connections 
for a first component, a second component, and a connection between the 
first and second components operable to represent the model; and 

if at least one of the first component, the second component, or the 
connection does not exist, defining the first component, the second 
component, or the connection which does not exist. 

6. (amended) The software proc e ss of claim 4 further including 
mapping either the input parameter of or the output parameter to at least a 
portion of the first model, the mapping operable to assign the mapped 
parameter to the portion. 

7. (amended) The software process of claim 4 further including defining 
an event, the event operable to identify when to use the method. 

8. (amended) The software process of claim 4 further including 
determining the existence of at least one other method. 

9. (amended) The software process of claim 9 further including 
providing a processing order, the processing order operable to define the 
order in which the method will be processed relative to a plurality of other 
methods awaiting processing. 
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10. (amended) The software process of claim 1 further including: 
determining whether the user desires to modify at least one of the input or 
output parameters; and modifying at least one of the input or output 
parameters if the user so desires. 

1 1 . (amended) A computer readable medium for storing a computer 
executable software program for determining a solution to a task using a 
plurality of knowledge acquisition approaches, the program including 
instructions for: 

defining the task; 
defining the solution; 

selecting a knowledge acquisition approach from a group consisting of 
a task-method-knowledge approach or a structure-behavior-function approach 
processing the task using the selected approach; 

determining whether the task includes at least one portion to be processed 
using the nonselected approach; 

the determining of the solution of the task further comprising using an 
SBF behavior and encoding the behavior using a TMK hierarchy which is 
collected from the user. aa4 
d e t e rmining whothor the so l ut i on has be e n found. 

12. (original) The medium of claim 11 wherein the program further includes 
instructions for storing an output generated by processing the portion; and 
using the output as an input to the task. 
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13. (original) The medium of claiml 1 wherein the program further includes 
instructions for redefining the task if the solution is not found. 

14. (original) The medium of claim 11 wherein the program further 
includes instructions to provide at least one interface enabling interaction with 
the program. 

15. (original) The medium of claim 11 wherein the program further includes 
instructions for redefining the solution if the solution is not found. 

16. (amended) A computer system for providing a solution to a task 
through information processing, the system including: 

a processor; 

a memory accessible to the processor; and 
software, a portion of which is stored in the memory, the software including 
instructions for: 

accepting at least a first parameter to define the task; 

accepting at least a second parameter to define the solution; 

accepting an initial approach for processing the task; 

determining whether to use a task-method-knowledge approach 

or a structure-behavior-function approach for processing the task, the 

determination based on the specified initial approach; 

processing the task using the determined approach based on 

the first parameter; 
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the processing of the task further comprising using an SBF 
behavior and encoding the behavior using a TMK hierarchy which is 
collected from the user; 
and 

determining whether the solution is found based on the second 
parameter. 

17. (original) The system of claim 16 wherein the software further includes 
instructions for, if the determined approach is the task-method-knowledge 
approach: 

determining whether a first portion of the task should be processed 
independently; 

determining whether to use the task-method-knowledge approach or 
the structure-behavior-function approach for processing the first portion if the 
first portion of the task should be processed independently; and 

processing the first portion using the determined approach. 

18. (original) The system of claim 17 wherein the software further includes 
instructions for, if the determined approach is the structure-behavior-function 
approach: 

determining whether a second portion of the task should be processed 
independently using the task-method-knowledge approach; and 

processing the second portion using the task-method-knowledge 
approach if the second portion should be processed independently. 
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19. (original) The system of claim 16 wherein the software further includes 
instructions for modifying the first parameter if the solution is not found. 

20. ( amende d) The system of claim 16 wherein the software further 
includes instructions for modifying the second parameter if the solution is not 
found. 
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